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Applicant's Response 

In Applicant's Response dated 24 October 2005, Applicant amended Claims 1-6, 
9, 15, 16 and 21-23, and argued against all rejections previously set forth in the Office 
Action dated 5 April 2005. 

Claim Rejections - 35 USC § 102 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

Claims 1-23 remain rejected under 35 U.S.C. 102(b) as being anticipated by 
Stone, Brad etal., UNIX Fault Management: A Guide for System Administration . 
(Prentice Hall PTR, ©1999). 
Claim 1: 

Stone discloses a method carried out by a status engine for monitoring services 
of an information technology (IT) environment (see Chapter 6 "Monitoring Network 
Services," Pages 1-5 of 5 - Stone discloses this limitation in that the book discloses 
monitoring network services), comprising: 

• storing a representation of a service hierarchy (see Chapter 9 "Using Event 
Correlation Tools" Pages 1-14 of 14 - Stone discloses this limitation in that the 
book discloses event correlation tools for use in clustered environments. Stone 
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expressly discloses that multiple nodes of the managed enterprise may notice 
the failure of a shared disc device and send "critical event" error messages to the 
enterprise management station. When this happens, the event correlation tool 
operates to intelligently filter and consolidate the messages. This discloses * 
"storing a representation of a service hierarchy" in at least two ways. Firstly, the 
management station is at the top of the "service hierarchy," with the multiple 
nodes being "subordinate" to the management station and the shared disc 
device being "subordinate" to the multiple nodes. The network administration 
system comprises the relationships of the network components and the rules for 
reporting errors and correlating the error messages. Thus, the network 
administration system disclosed in Stone "stores" a "representation of a service 
hierarchy." Secondly, the event correlation rules establish procedures for 
reporting events that are interrelated. As indicated in the example mentioned 
above, the rules may comprise procedures for handling the situation that arises 
when multiple nodes notice the failure of a shared disc device. Such rules 
would recognize the "status" of the "subordinate" shared disc device (i.e., 
"failed" status), efficiently handle the multiple error messages being reported by 
the "superordinate" multiple nodes, and report the error to the enterprise 
management station in an efficient manner. Thus, the rules recognize the 
"hierarchy" of the multiple nodes (i.e., "superordinate services") and the shared 
disc (i.e., "subordinate service") and "stores" the "service hierarchy." Stone also 
discloses this limitation in that the book discloses the Seagate NerveCenter 
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enterprise management product - hereinafter, Seagate - that uses rules-based 
filtering and advanced correlation to pinpoint root causes of critical network 
issues. Seagate also uses behavioral models to define the relationships 
between critical conditions and specific corrective actions. Seagate also includes 
models for monitoring network traffic, performance, status, security and error 
conditions of the components within the enterprise. Finally, Seagate correlates 
across network devices, UNIX systems and NT systems using a distributed 
management model. In performing these functions, Seagate "stores" a 
"representation" of a "service hierarchy," and these models define the 
hierarchical relationships between the components of the enterprise - i.e., the 
"superordinate services" and the "subordinate services."), wherein the stored 
representation includes service elements (Stone discloses this limitation in that 
the components of the "stored representations" mentioned in the above 
discussions comprise "service elements." Specifically, the management 
station, the multiple nodes and the shared disc device are "service elements." 
Also, specifically, the models that monitor network traffic, performance, status 
and error conditions of the components within the enterprise are "service 
elements."), wherein each of the service elements represents a service of the IT 
environment (Stone discloses this limitation in that the "service elements" 
mentioned in the above discussions "represent" a "service" in that users of the 
managed network enterprise access the nodes and the shared disc device to use 
the applications of the network enterprise. That is, the users access the 
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components of the enterprise network to use the applications of the enterprise 
network.) and each of the service elements has an associated service status 
(Stone discloses this limitation in that, as indicated in the above discussion, the 
event correlation tools monitor the "service elements" to determine their "status" 
and report errors. Similarly, as indicated in the above discussion, Seagate 
monitors the "status" of the enterprise network components.), wherein the service 
hierarchy includes at least one superordinate service element and at least one 
subordinate service element (As indicated in the above discussion, the 
"hierarchy" established by the event correlation tools comprises "superordinate 
service elements" and "subordinate service elements." Similarly, the models 
established by Seagate comprise "superordinate service elements" and 
"subordinate service elements."); and 
• calculating a status of the at least one superordinate service element by 
considering status dependency and propagation between the service elements 
within the service hierarchy, according to one or more rules (As indicated in the 
above discussion, Stone discloses using event correlation tools and service 
models for monitoring the status of enterprise network devices in enterprise 
network management. The status of any "superordinate" component within the 
service model will depend upon the statuses of "subordinate" components and 
the propagation of data from those "subordinate" components in that a problem 
occurring at a "subordinate" component will affect a "superordinate" component. 
Thus, any "calculation" of the "status" of a "superordinate" service will include 



Application/Control Number: 09/816,940 Page 6 

Art Unit: 2176 

consideration of the "status dependency" and "propagation" between "service 
elements." Also, see Chapter 4 "Using Graphical Status Monitors," and 
"OpenView Network Node Manager" Pages 1 -3 of 1 6 - Stone discloses this 
limitation in that graphical status monitors display hierarchical maps that display 
status information regarding the components within the service model. The 
maps display the health of the objects represented and enable the user to drill 
down through complex network topologies. Also, see Chapter 4 "ClusterView," 
Pages 3-5 of 16 - Stone discloses this limitation in that the MC/ServiceGuard 
network monitoring tool monitors clusters. That is, the software on each system 
monitors other systems on the network. Whenever failures occur at the 
monitored systems on the network, the software detects the problem and restarts 
critical applications at another node on the network. Stated differently, 
MC/ServiceGuard monitors systems, processes and the network, and, whenever 
it detects a failure at any of the monitored components of the network, all critical 
resources are moved to another node within the network. Also, see Chapter 7 
"Monitoring the Application," and "Comparison of Application Monitoring 
Products" Pages 1-2 of 2 - Stone discloses this limitation in that it discloses that 
maintaining application availability means maintaining the availability and 
performance of all components that the application depends on, including 
databases, networks, storage, and the system itself. Also, Stone expressly 
states that the use of MC/ServiceGuard with Event Monitoring Service (EMS) 
enables a user to make explicit links between an application and its dependent 
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resources. Thus, the status of an application depends upon the statuses of any 
components on which the application relies, and rules for determining the 
dependent status of the application will depend upon and consider the statuses 
of the underlying components.), 
wherein the status of the at least one superordinate service element depends on a 
status of the at least one subordinate service element (As indicated in the above 
discussion, the status of a "superordinate" component will depend upon the statuses of 
"subordinate" components.), 

wherein the rules define the dependency of the status of the at least one superordinate 
service element on the status of the at least one subordinate service element and a 
propagation of the status from the at least one subordinate service element to the at 
least one superordinate service element (As indicated in the above discussion, Stone 
discloses enterprise management tools that allows network administrators to write rules 
for network components that depend on other underlying components.), and 
wherein the rules include at least one of: 

• a rule that is based on additional attributes of at least one of the service elements 
other than the service hierarchy status (HP includes rules that are based on 
"additional attributes of the service other than the status" in that it filters out 
redundant events before forwarding them to the management station and it 
forwards events to the management station only after a user-defined threshold is 
met. MasterCell includes rules that are based on "additional attributes of the 
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service other than the status" in that it regulates events by holding repetitive 
occurrences of events until a threshold is met.); 

• a rule that ignores the at least one subordinate services element (HP includes 
rules that "ignore subordinate services" in that it can be configured to filter out 
information that is unnecessary in order to identify the root cause of a problem 
and correct said problem.); 

• a rule that is defined by a' user on the basis of at least one of i) logical and ii) 
arithmetical operations of the status or the attributes of the at least one 
subordinate services element (HP includes rules that are "defined by logical and 
arithmetical operations of the status of subordinate services or of said messages 
or of said attributes" in that it reduces event storms by suppressing repeated 
events using a time-based filter. HP also allows users to create their own 
monitor scripts, which includes both "logical" and "arithmetical" operations of the 
status of subordinate services or of said messages or of said attributes.); and 

• a rule that is programmed individually by a user (HP allows users to create their 
own monitor scripts; Seagate allows the user to define the rules via a GUI.). 

Claim 2: 

Stone discloses the method of Claim 1, wherein the rules, when the status of the 
at least one superordinate service element is calculated, include: 

• status propagation rules that each have as an input only one parameter, wherein 
the parameter is the status of the at least one subordinate service element (HP 
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includes "status propagation rules" that are based solely on the status of the 
monitored service), and 
• status calculation rules that have as an input one or more parameters, selected 
from the group consisting of: the propagated status of the at least one 
subordinate services elements, messages coming from services of the IT 
environment and additional attributes (HP includes "status calculation rules" in 
that it includes filters that are based on status severity of subordinate services, 
the particular types of messages and other factors such as various attributes of 
the originating system). 

Claim 3: 

Stone discloses the method of Claim 1, wherein the calculation of the status of 
the at least one superordinate service element depends on any combination of three 
different types of input data: the status of the at least one subordinate service element, 
messages affecting the at least one superordinate service element and the additional 
attributes of the service elements (as explained in the above rejection for Claim 2, Stone 
discloses these limitations). 

Claim 4: 

Stone discloses the method of Claim 1, wherein the additional attributes can take 
values that are different from possible values of the status of the service elements (the 
"additional attributes" can take values that are "different from the possible values of the 
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status of the services" in that the "additional attribute" values comprise numeric values 
that affect the forwarding of events only after a user-defined threshold is met and the 
"status" values comprise the severity of the detected problem, such as "minor warning" 
and "critical"). 

Claim 5: 

Stone discloses the method of Claim 1, wherein the status of the at least one 
superordinate service element is only calculated if certain attributes of the at least one 
superordinate service element are set (as explained in the above rejection for Claim 1 , 
HP discloses a rule that is "based on additional attributes of a service;" thus, "certain 
attributes" of the superordinate service are "set" and the status of the superordinate 
service is calculated). 

Claim 6: 

Stone discloses the method of Claim 1, wherein specific subordinate service 
elements of the at least one subordinate service element are individually treated for the 
calculation of the status of the at least one superordinate service element (HP includes 
tools that allow the user to customize monitoring rules to address each subordinate 
service individually). 
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Claim 7: 

Stone discloses the method of Claim 1, wherein user-specific external data is . 
included in the rules (HP includes "user-specific external data in the rules" in that it 
allows the user to customize monitoring rules to address numerous different network 
components). 

Claim 8: 

Stone discloses the method of Claim 1, wherein time of the day information is 
included in the rules (HP includes "time of the day information" in the rules in that it 
allows the user to customize monitoring rules to enable events to be forwarded to the 
appropriate management station in a global environment based on the time of day). 

Claim 9: 

Stone discloses a computer system for monitoring services of an information 
technology (IT) environment, wherein the computer system monitors the services based 
on a service hierarchy (as indicated in the above rejection for Claim 1, Stone discloses 
a "computer system" that performs these functions), wherein a stored representation of 
the service hierarchy includes service elements representing services of the IT 
environment and each having an associated service status, wherein the service 
elements include at least one superordinate service element and at least one 
subordinate service element (as indicated in the above rejection for Claim 1 , Stone 
discloses these limitations), wherein a status of the at least one superordinate service 
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element depends on a status of the at least one subordinate service element (as 
indicated in the above rejection for Claim 1, Stone discloses these limitations), the 
system comprising: 

• a status engine for calculating the status of at least one of the service model 
elements, wherein the status engine can calculate the status of the at least one 
subordinate service element by considering status dependency and propagation 
between the service model elements within the service hierarchy, according to 
one or more rules (as indicated in the above rejection for Claim 1 , Stone 
discloses these limitations); 

• a user interface for configuring the rules (HP includes a "user interface for 
configuring the rules" in that it comprises an interface used to define monitoring 
conditions); and 

• a graphical display for visualizing the monitoring results (HP includes a "graphical 
display for visualizing the monitoring results" in that it comprises an interface for 
monitoring the components of the system), 

wherein the rules define the dependency of the status of the at least one superordinate 
service element on the status of the at least one subordinate service element and a 
propagation of the status from the at least one subordinate service element to the at 
least one superordinate service element (as indicated in the above rejection for Claim 1 , 
Stone discloses this limitation), and 
wherein the rules include at least one of: 
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• a rule that is based on additional attributes of at least one of the service elements 
other than the status; 

• a rule that ignores the at least one subordinate services element; 

• a rule that is defined by a user on the basis of at least one of i) logical and ii) 
arithmetical operations of the status or the additional attributes of the at least one 
subordinate services element; and 

• a rule that is programmed individually by a user (as indicated in the above 
rejection for Claim 1, Stone discloses each of these rules). 



Claim 10: 

Stone discloses the computer system of Claim 9, wherein the interface for 
configuring the rules is a graphical user interface (HP includes a "graphical user 
interface for configuring the rules" in that it comprises an interface used to define 
monitoring conditions). 

Claim 11: 

Stone discloses the computer system of Claim 9, wherein the interface for 
configuring the rules is an application programming interface to other programming 
languages (HP includes APIs for configuring monitoring conditions). 
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Claim 12: 

Stone discloses the computer system of Claim 9, wherein the interface for 
configuring the rules is a script programming language of which a syntax is provided by 
the status engine (HP includes a "script programming language of which the syntax is 
provided by the status engine" in that it comprises allows the user to customize rules 
that are managed by an "Edit Adviser Syntax" option). 

Claim 13: 

Stone discloses the computer system of Claim 9, wherein the status engine is 
capable of handling a graph structure of the IT network of services in which each of the 
services can have one or more depending services and one or more services on which 
each of the services depends (HP is capable of handling a "graph structure of the IT 
network of services" in that it allows the user to customize monitoring rules for any of 
the components of the network). 

Claim 14: 

Stone discloses the computer system of Claim 9, wherein the dependencies 
between the services of the IT environment are visualized as a graphical representation 
(HP includes a "graphical representation" of the dependencies between the services in 
that it includes a hierarchical display of the components of the network). 



Application/Control Number: 09/816,940 Page 15 

Art Unit: 2176 

Claim 15: 

Stone discloses the computer system of Claim 14, wherein the status and status 
changes of the service elements are visualized in a graphical representation (HP 
includes a "graphical representation of e status and status changes of the services" in 
that it comprises graphical status monitors). 

Claim 16: 

Claim 16 recites computer software for performing the method of Claim 1 . Thus, 
Stone discloses every limitation of Claim 16, as indicated in the above rejection for 
Claim 1. 

Claims 17-20: 

Claims 17-20 recite limitations that were also recited in Claims 9-12, respectively. 
Thus, Stone discloses every limitation of Claims 17-20, as indicated in the above 
rejections for Claims 9-12. 

Claims 21-23: 

Stone discloses all limitations of Claims 1, 9 and 16, wherein the status of at 
least one of the service model elements further depends on one or more messages 
coming from services of the IT environment and affecting the status of the at least one 
of the service model elements and wherein the rules further define the dependency of 
the status of the at least one of the service model elements on the messages (Stone 
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discloses this limitation in that the network monitoring tools comprise messages 
regarding the health of the network components being monitored. These messages are 
generated and sent according to the rules of the network monitoring tools. As indicated 
in the above discussion, the status of one network component might depend on the 
statuses of other network components. Thus, a message regarding a problem with a 
"subordinate" component will affect the status of "superordinate" component.). 



Response to Arguments 

Applicant's arguments filed 24 October 2005 have been fully considered but they 
are not persuasive. 

Arguments for Claims 1, 9 and 16: 

Applicant argues that Stone fails to disclose a method for calculating the status of 
a superordinate service element "by considering status dependency and propagation 
between the service elements within the service hierarchy" and rules that "define the 
dependency of the status of a superordinate service element on the status of a 
subordinate service model element and a propagation of the status from the 
subordinate service model element to the superordinate service model element" 
because the Seagate behavior models discussed in Stone define relationships between 
certain conditions and specific corrective actions rather than defining dependency 
relationships between network elements (emphasis added). Thus, Applicant argues, 
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Stone fails to disclose consideration of: 1) relational dependencies between network 
elements; and 2) propagation of data between the network elements. Applicant's 
arguments for Claims 9 and 1 6 correspond to the arguments in support of Claim 1 . See 
Response - Page 10, second paragraph through Page 1 1 , first paragraph. 

The examiner disagrees. 

Firstly, the relevant language of Claim 1 is: 

• "... a service hierarchy, . . . wherein the service hierarchy includes at least one 
superordinate service element and at least one subordinate service element 
(see Line 4 and Lines 7-9); 

• "calculating a status of the at least one superordinate service element by 
considering status dependency and propagation between the service elements 
within the service hierarchy, according to one or more rules 11 (see Lines 11-13); 
and 

• " wherein the rules define the dependency of the status of the at least one 
superordinate service element on the status of the at least one subordinate 
service element and a propagation of the status from the at least one subordinate 
service element to the at least one superordinate service element (see Lines 16- 
19). 

These limitations essentially recite: a service model that comprises a superordinate 
service and a subordinate service, wherein a status of the superordinate service 
depends upon a status of the subordinate service; and determining the status of the 
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superordinate service. Regarding the above listed limitations, the third limitation is 
essentially repeats the second limitation. 

As indicated in the above rejection for Claim 1 , Stone discloses a network 
administration system that comprises the relationships of the network components and 
the rules for reporting errors and correlating the error messages, "service hierarchies" 
that comprise "superordinate service elements" and "subordinate service elements." 
Stone also discloses 

Also, as indicated in the above rejection for Claim 1 , Stone discloses the 
MC/ServiceGuard network monitoring tool. Stone expressly discloses that ., 
MC/ServiceGuard monitors systems, processes and the network, and, whenever it 
detects a failure at any of the monitored components of the network, all critical 
resources are moved to another node within the network. Thus, the status of all 
network components are simultaneously monitored, and upon detection of failure at any 
of the components, corrective action is taken by moving resources to other network 
components. To perform these functions, MC/ServiceGuard includes monitoring rules 
to consider the status of each network component and the interdependencies of each 
network component with all of the other network components. 

Finally, Stone expressly states that the use of MC/ServiceGuard with EMS 
enables a user to make explicit links between an application and its dependent 
resources. Thus, the status of an application depends upon the statuses of any 
components on which the application relies, and rules for determining the dependent 
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status of the application will depend upon and consider the statuses of the underlying 
components. 

Accordingly, Stone discloses: 

• "... a service hierarchy, . . . wherein the service hierarchy includes at least one 
superordinate service element and at least one subordinate service element? 

• " calculating a status of the at least one superordinate service element by 
considering status dependency and propagation between the service elements 
within the service hierarchy, according to one or more rules;" and 

• "wherein the rules define the dependency of the status of the at least one 
superordinate service element on the status of the at least one subordinate 
service element and a propagation of the status from the at least one subordinate 
service element to the at least one superordinate service element" 

Moreover, in the Specification of the present invention, Applicant states that 
service management tools enable the user to build management models of an IT 
environment that represent the elements that make up the service and the relationships 
and dependencies between those elements (see Specification - Page 2, Lines 9-16): 
One service on a computer network may, and often does, depend on the availability and 
status of other services on the network. Thus, the status of one service may depend on 
the statuses of other services on the network, and rules for determining the status of a 
service will consider the statuses of the underlying services. Finally, in the Specification 
of the present invention, Applicant also states that service management tools "provide 
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the status of any of those services in the light of dependencies amongst them" (see 
Specification - Page 2, Lines 16-18). Thus, the status of a service is dependent upon 
the statuses of any underlying services on the network. 



Conclusion 

All claims are drawn to the same invention claimed in the application prior to the 
entry of the submission under 37 CFR 1.114 and could have been finally rejected on the 
grounds and art of record in the next Office action if they had been entered in the 
application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE 
FINAL even though it is a first action after the filing of a request for continued 
examination and the submission under 37 CFR 1.114. See MPEP § 706.07(b). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Doug Hutton whose telephone number is 571-272-4137. 
The examiner can normally be reached on Monday-Friday from 8:00 AM to 5:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Heather Herndon, can be reached at (571) 272-4136. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is (571) 272- 
2100. 



WDH 

December 8, 2005 
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